# 使用git rebase合并多次commit

# 1. 背景

一个repo通常是由一个 Team 中的多个人共同维护,如果需要增加新 Feature,那么就是一个 Feature 分支了。由于开发中各种修改,本 Feature 分支多次 commit 。最后提交 master 后,会看到乱七八糟的所有增量修改历史。其实对别人来说,我们的改动应该就是增加或者删除,给别人看开发过程的增量反而太乱。于是我们可以将 feature 分支的提交合并后然后再merge到主干这样看起来就清爽多了。

记得知乎上有个帖子提问为啥vue的作者尤大大在开发vue的时候,提交历史能做到如此清爽。Git commits历史是如何做到如此清爽的? - 知乎 (opens new window)

image-20200509152716378

# 2. rebase简介

rebase 的作用简要概括为:可以对某一段线性提交历史进行编辑、删除、复制、粘贴;

因此,合理使用 rebase 命令可以使我们的提交历史干净、简洁!

但是需要注意的是:

WARNING

不要通过 rebase 对任何已经提交到公共仓库中的 commit 进行修改(你自己一个人玩的分支除外)

# 3. 反面例子

  • 新建一个repo rebase-test

  • 新建开发分支dev;在开发分支是commit了三次然后mergemaster分支;

  • 然后git log或者git log --oneline

  • 可以发现dev分支上的每次commit都体现到了master

fb28c8d (HEAD -> master, origin/master, origin/dev, origin/HEAD, dev) fix: 第三次提交
47971f6 fix: 第二次提交
d2cf1f9 fix: 第一次提交
26bac61 Initial commit

如果用git log可以按s向下翻log

git log --oneline 可以一行展现

# 4. 具体操作

当我们在本地仓库中提交了多次,在我们把本地提交push到公共仓库中之前,为了让提交记录更简洁明了,我们希望把如下分支B、C、D三个提交记录合并为一个完整的提交,然后再push到公共仓库。

image-20200509152818874

这里我们使用命令:

git rebase -i  [startpoint]  [endpoint]

其中-i的意思是--interactive,即弹出交互式的界面让用户编辑完成合并操作,[startpoint] [endpoint]则指定了一个编辑区间,如果不指定[endpoint],则该区间的终点默认是当前分支HEAD所指向的commit(注:该区间指定的是一个前开后闭的区间)。
在查看到了log日志后,我们运行以下命令:

git rebase -i 36224db

或者

git rebase -i HEAD~3 

然后我们会看到如下界面:

image-20200509152942631

上面未被注释的部分列出的是我们本次rebase操作包含的所有提交,下面注释部分是git为我们提供的命令说明。每一个commit id 前面的pick表示指令类型,git 为我们提供了以下几个命令:

pick:保留该commit(缩写:p)

reword:保留该commit,但我需要修改该commit的注释(缩写:r)

edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e)

squash:将该commit和前一个commit合并(缩写:s)

fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f)

exec:执行shell命令(缩写:x)

drop:我要丢弃该commit(缩写:d)

根据我们的需求,我们将commit内容编辑如下:

pick d2cf1f9 fix: 第一次提交

s 47971f6 fix: 第二次提交

s fb28c8d fix: 第三次提交

上面的意思就是把第二次、第三次提交都合并到第一次提交上

然后wq保存退出后是注释修改界面:

image-20200509153037582

可以再浏览态 按下两个dd可以删除一行

最终的编辑效果如下:
image-20200509153130098

编辑完保存即可完成commit的合并了:

image-20200509153230976

最后查看log可以发下提交合并了

image-20200509153345451

# 5. 参考文献

左鹏飞 (opens new window)

最后编辑时间: 5/11/2020, 9:14:29 AM